Various network protocols have been developed to allow the transfer of information, such as voice, video or application data, between endpoints (either network infrastructure or devices subscribed to the network). In all cases, the endpoints are given a finite amount of resources to accomplish their information transfer. Scheduling is the process by which the endpoint determines the order in which information multiplexed from many sources is sent over the transport.
An example is a cellular phone designed to use the IS-136 or GSM protocol, which is given a fixed number of timeslots per second to transmit audio. In this case, the required throughput is known a priori and sufficient bandwidth is guaranteed to support the lone data source. The scheduler simply transfers audio packets on a first in, first out basis without fear that packets will timeout (i.e., expire because they remained unsent for their allotted lifetime).
Another example is the packet data component of the TETRA protocol. In this case, each service context establishes its own private link. These links might provide a different quality of service (e.g., a specific priority level, confirmed or unconfirmed transfer, etc.). Again, in this case, since the data on a link is of the same class, it can be scheduled using a simple first in, first out basis.
As customer needs expand to high data rate applications, networks will evolve towards more universal protocols that can support multiple service types at the same time. A common endpoint in such a network might be supporting a video call with associated audio, and at the same time, transferring files or downloading web pages over the Internet. Efficient designs will forgo the wasteful setup of multiple links or contexts and instead multiplex all information over one, common connection.
The joining of all information sources onto a common connection will introduce numerous problems that have yet to be encountered. For example, packets on a link are typically identified using a finite number sequence that wraps around in a modulo manner. When confirmed and unconfirmed packets share the same link, the opportunity arises for a confirmed packet to block the transmission of a rapid arrival unconfirmed packet stream (e.g., from an audio or video CODEC). That is, the packet number of the fast arriving unconfirmed packets might wrap around to the packet number held by the confirmed packet, which has yet to resolve. This might happen due to the confirmed packet being a low priority or requiring multiple attempts to successfully transfer.
In previous systems, such ambiguity was not an issue. A technique common to the art and known as windowing was used to limit the number of packets in flight on a confirmed link at any given moment. Packets on an unconfirmed link could be sent in order to prevent any packet number wrapping. It is a necessity that any new protocol also be capable of avoiding packet number ambiguity. Other desirable traits would be to minimize throughput delay, guarantee the quality of service and provide support for as many quality levels as needed.
Thus, there exists a need for sequencing datagram transmissions.